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(1) Real Party in Interest 

A statement identifying the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

A statement identifying the related appeals and interferences which will directly 
affect or be directly affected by or have a bearing on the decision in the pending appeal 
is contained in the brief. 

(3) Status of Claims 

The statement of the status of the claims contained in the brief is correct. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection 
contained in the brief is correct. 

(5) Summary of Invention 

The summary of invention contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The statement of the grounds of rejection to be reviewed on appeal is correct. 

(8) Claims Appealed 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(9) Prior Art of Record 

5,038,284 KRAMER 8-1991 

5,243,331 McCAUSLAND et al 9-1 993 
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(10) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 

(a) Claims 1-5, 7-15, and 34-36 rejected under 35 U.S.C. 112, first paragraph, 
as containing subject matter which was not described in the specification in such a way 
as to enable one skilled in the art to which it pertains, or with which it is most nearly 
connected, to make and/or use the invention. The fourth paragraph of Claim 1 contains 
the limitation of "in response to detecting that an aggressor participant's hit or lift trade 
command would execute a trade in excess of what the aggressor participant may have 
intended,". However, the specification does not enable one of ordinary skill in the art at 
the time the invention was made to determine how the invention would be able to 
determine what the aggressor participant may have intended. The specification 
contains no reference to the aggressor participant's intentions nor to any artificial 
intelligence program which could possibly be used to predict the intentions of a human 
participant. For purposes of examination, the Examiner will consider this limitation as 
meaning that the invention will ensure that the trade is within the normal preset 
guidelines, i.e. minimum or maximum bid, offer, or quantity, such as is standard practice 
within the industry. 

(b) Claims 1-5, 7-18, 20-23, and 34 are rejected under 35 U.S.C. 102(b) as 
being separately anticipated by McCausland et al (5,243,331) and Kramer (5,038,284). 
In order to provide a more concise action on this application, the Examiner will cite 
features of the claim followed by citation of the appropriate passages from each of the 



Application/Control Number: 09/859,661 Page 4 

Art Unit: 3622 

two references. However, the Applicant should consider each reference as a separate 
and distinct rejection under 35 U.S.C. 102(b). 

Claim 1 : McCausland and Kramer each disclose a computer trading system, 
comprising: 

a. Workstations with displays for presenting pending market conditions 
(McCausland . Figure 2)(Kramer, Figure 3a and col 1 1, lines 9-12); 

b. A server programmed to conduct trading sequences responsive to 
trade commands received from the workstation users (McCausland . Figure 1; col 22, 
lines 43-63; and col 24, lines 7-67)(Krarner, col 5, lines 23-31 and col 9, lines 42-65); 
and 

c. A state in which the participant is given the chance to amend or cancel 
the trade prior to the automatic execution of the trade ( McCausland . col 25, lines 8- 
30)(Kramer, col 1 2, lines 51 -61 ). 

While neither reference uses the terminology "trade states" to describe various 
parts of the computer trading system operation, McCausland discusses that the system 
can monitor the scheduling of operations and can "change the operational state of the 
market memory program 90 according to a predetermined time schedule" (col 10, lines 
45-51 ) and during a fatal error recovery will "re-build the exact state of the market prior 
to the fatal error" (col 10, lines 30-44). McCausland further discloses using a menu 
program which will display to the user a list of choices, "and the user is prompted for 
selection, which will be the next programs to run" (col 11, lines 64-68). McCausland 
also discloses that at least some of the data being displayed changes to a default 
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condition upon the user pressing the Bid, Offer, Hit, or Take keys (col 23, lines 1-5) with 
the defaults being unique and different for each of these keys. Kramer discloses that in 
response to menu selections (i.e. pressing the Hit key, the Bid key, etc.) certain keys 
will "light up to indicate which are appropriate answers to menu questions" (col 4, lines 
37-40 and Claim 7). Therefore, both references disclose "defining the ability of various 
participants to participate in said trading activities" which is the Applicant's definition of 
trade specific states in Claim 1 . 

Claim 2: McCausland and Kramer each disclose a computer trading system and 
in Claim 1 above, and further disclose that the system is run using a stored program 
that controls the trading ( McCausland . col 8, lines 25-57)( Kramer . col 10, line 30 - col 
11, line 30). 

Claim 3: McCausland and Kramer each disclose a computer trading system as in 
Claim 1 above, and further disclose the user entering commands such as bids, offer, 
hits, or lifts ( McCausland . col 22, lines 64-68) (Kramer . col 12, lines 3-37). 

Claims 4, 5, and 7: McCausland and Kramer each disclose a computer trading 
system as in Claim 1 above, and further disclose the trading states comprising Workup, 
Workdown, and When states as defined in the table in Figure 1 1 (McCausland . col 23, 
lines 6-68)( Kramer . Figure 2 and col 6, lines 17-39 and col 12, lines 51-61). 

Claims 8: McCausland and Kramer each disclose a computer trading system as 
in Claim 1 above, and further disclose display a bid side and an offer side or a market 
( McCausland . col 18, lines 49-57 and col 20, lines 25-26) (Kramer . Figure 3a and col 12, 
lines 10-12). 
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Claim 9: McCausland and Kramer each disclose a computer trading system as in 
Claim 8 and further disclose displaying information as to the size of uncleared 
(unreconciled) bids and offers (McCausland . col 18, lines 49-57) (Kramer . col 12, lines 
43-46). 

Claims 10-12: McCausland and Kramer each disclose a computer trading system 
as in Claim 8 above, and further disclose display a list (queue) of bids and offers 
showing the participants, time and size of entry, and price (McCausland . Figures 6-9 
and col 18, line 34 - col 22, line 38) ( Kramer . Figure 3a; col 12, lines 3-13; and col 20, 
lines 43-65). 

Claim 13: McCausland and Kramer each disclose a computer trading system as 
in Claim 12 above, and further disclose displaying information regarding the hits or lifts 
by the participant (McCausland . col 20, lines 25-26)(Kramer, Figure 3a and col 12, lines 
10-12). 

Claim 14: McCausland and Kramer each disclose a computer trading system as 
in Claim 1 above, and further disclose the item being a commodity, security, index, or 
futures contract ( McCausland . col 1, lines 30-33 and col 4, lines 8-1 4) f Kramer , col 1, 
lines 8-52). 

Claim 15: McCausland and Kramer each disclose a computer trading system as 
in Claim 1 above, and further disclose the bids and offers pertain to a futures contract 
( McCausland . col 14, lines 1 9-20)(Kramer, col 1, lines 8-52). 
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(c) Claims 16-23 are rejected under 35 U.S.C. 102(b) as being separately 
anticipated by or, in the alternative, under 35 U.S.C. 103(a) as being separately obvious 
over McCausland et al (5,243,331 ) and Kramer (5,038,284). 

Claim 16: McCausland and Kramer each disclose a computer trading system, 
comprising: 

a. Data processor for providing a trading protocol (McCausland . col 10, 
lines 45-51 )(Kramer, col 9, lines 42-65); 

b. Custom designed keypad with specially assigned keys (McCausland . 
Figure 3 and col 6, line 42 - col 8, line 23)( Kramer , Figure 3a and col 16, table); and 

c. Display for presenting pending bids and offers (McCausland . col 24, 
lines 2-5 )( Kramer . Figure 3a and col 1 1 , lines 9-12). 

While both references explicitly disclose that the keyboard contains a plurality of 
trade execute keys (at least one buy key and at least one sell key), it is not expiiciiiy 
disclosed that the keyboard has a separate buy key and a separate sell key (i.e. a set of 
trade execute keys) assigned to each of a plurality of specific securities. However, 
Kramer discloses using special function keys on the keyboard to provide simplified data 
entry and further discloses altering these function keys to provide the desired 
functionality (col 3, line 63 - col 4, line 4). McCausland also discloses a special purpose 
keypad with a variety of special functions assigned to the function keys. While one 
exemplary mapping is disclosed, it is also disclosed that "other mappings of keypad 200 
are possible and are contemplated" (col 6, line 40 - col 8, line 23). Thus, both 
references disclose that the keys on the keyboard/keypad may be altered to provide the 
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desired functionality. The Examiner also notes that it is common for data processing 
keyboards to have 10-12 programmable function keys. Therefore, it is inherent that 
each of the programmable keys may be programmed as separate buy and sell keys for 
specific securities; or, at least, it would have been obvious to one having ordinary skill in 
the art at the time the invention was made that a plurality of buy and sell keys could be 
set up, one pair for each desired security. One would have been motivated to set up 
special buy and sell keys for specific securities in order to increase the speed in which 
the operator could enter selections as discussed as being desirous by both references. 

Claim 1 7: McCausland and Kramer each disclose a computer trading system as 
in Claim 16 above and further disclose a Cancel key ( McCausland , "reject" col 7, lines 
43-47 and col 23, lines 27-29M Kramer . "NT", col 16, table). 

Claim 18: McCausland and Kramer each disclose a computer trading system as 
in Claim 16 above, and further disclose displaying the price and size of the bids and 
offers ( McCausland . col 18, lines 49-57 and col 20, lines 25-26)( Kramer , Figure 3a and 
col 12, lines 10-12). 

Claim 20: McCausland and Kramer each disclose a computer trading system as 
in Claim 18 above, and further disclose moving to the When state (waiting) when a non- 
priority participant enters a hit or lift (entry while unreconciled entries are 
outstanding)( McCausland . col 9, lines 48-55; col 19, lines 28-38; and col 22, lines 41- 
62)( Kramer . col 12, lines 51-61). 
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Claim 21 : McCausland and Kramer each disclose a computer trading system as 
in Claim 16 above, and further disclose presenting (displaying) information based on the 
current trading state (i.e. bid information is displayed while in the bid state, offer 
information is displayed while in the offer state, etc.H McCausland . Figures 6-9 and col 
7, lines 7-38)(Kramer, Figure 3a and col 25, lines 9-16). 

Claim 22: McCausland and Kramer each disclose a computer trading system as 
in Claim 16 above, and further disclose the item being a commodity, security, index, or 
futures contract ( McCausland . col 1, lines 30-33 and col 4, lines 8-14)(Kramer, col 1, 
lines 8-52). 

Claim 23: McCausland and Kramer each disclose a computer trading system as 
in Claim 16 above, and further disclose the bids and offers pertain to a futures contract 
( McCausland . col 14, lines 1 9-20)(Kramer, col 1, lines 8-52). 

(d) Claim 19 is rejected under 35 U.S.C. 102(b) as being anticipated by 
McCausland et al (5,243,331 ). 

Claim 19: McCausland discloses a computer trading system as in Claim 16 
above, and further discloses terminating the bid/offer state upon entry of a hit or lift (col 
24, lines 64-67). 

(e) Claims 31-33 and 35-37 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over McCausland et al (5,243,331 ) and Kramer (5,038,284). In order to 
provide a more concise action on this application, the Examiner will cite features of the 
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claim followed by citation of the appropriate passages from each of the two references. 
However, the Applicant should consider each reference as a separate and distinct 
rejection under 35 U.S.C. 103(a). 

Claims 31-33, 35, and 36: McCausland and Kramer each disclose a computer 
trading system, comprising: 

a. Workstations with displays for presenting pending market conditions 
( McCausland . Figure 2) (Kramer . Figure 3a and col 1 1, lines 9-12); 

b. Central server programmed to conduct trading sequences responsive 
to trade commands received from the workstation users ( McCausland . Figure 1 ; col 22, 
lines 43-63; and col 24, lines 7-67)( Kramer , col 5, lines 23-31 and col 9, lines 42-65); 
and 

c. A state in which the participant is given the chance to amend or cancel 
the trade ( McCausland . col 25, lines 8-30) (Kramer . col 12, lines 51-61). 

While neither reference uses the terminology "trade states" to describe various 
parts of the computer trading system operation, McCausland discusses that the system 
can monitor the scheduling of operations and can "change the operational state of the 
market memory program 90 according to a predetermined time schedule" (col 10, lines 
45-51 ) and during a fatal error recovery will "re-build the exact state of the market prior 
to the fatal error" (col 10, lines 30-44). McCausland further discloses using a menu 
program which will display to the user a list of choices, "and the user is prompted for 
selection, which will be the next programs to run" (col 1 1 , lines 64-68). McCausland 
also discloses that at least some of the data being displayed changes to a default 
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condition upon the user pressing the Bid, Offer, Hit, or Take keys (col 23, lines 1-5) with 
the defaults being unique and different for each of these keys. Kramer discloses that in 
response to menu selections (i.e. pressing the Hit key, the Bid key, etc.) certain keys 
will "light up to indicate which are appropriate answers to menu questions" (col 4, lines 
37-40 and Claim 7). Therefore, both references disclose "defining the ability of various 
participants to participate in said trading activities" which is the Applicant's definition of 
trade specific states in Claim 1 . 

While neither reference explicitly discloses enabling the user to exclude or 
include third party participants from trading with the first participant when completing a 
trade with the second participant, Official Notice is taken that it is old and well known in 
the negotiation and auction arts that third party participants can be allowed to participate 
(included) or prevented from participating (excluded) during the negotiation and 
consummation of a transaction between the first and second parties. For example, in 
the normal Dutch (reverse) auction in which a first party is offering a quantity of a 
product for sale, when a second party enters a bid at a certain price, the auction is 
stopped while the second party is queried as to the desired quantity of the items, the 
second party is given a specified amount of time, such as two minutes, in which to 
consummate the trade. During this time, none of the third parties may enter bids nor 
participate in the negotiation of the quantity, i.e. they are excluded. However, if the 
second party does not purchase all of the items, third parties may be allowed to buy the 
remaining items at the same price as the second party, i.e. they are included (in support 
of this Official Notice, See Rockoff et al . "Design of an Internet-based System for 
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Remote Dutch Auctions", page 1 1 ). McCausland asks the user to Confirm or Reject 
the second party's bid/offer (col 20, lines 58-61 ) and discusses the differences between 
a "single-order" trader and a "multi-order" trader (col 22, lines 41-63) and how partial 
hits or offers are handled (col 24, line 64 - col 25, line 3). Kramer discusses at length 
how two traders resolve conflicts with unreconciled trades through one-on-one 
negotiation (col 12, lines 38-61 ). Therefore, it would have been obvious to one having 
ordinary skill in the art at the time the invention was made to allow the user (first party) 
to include or exclude other parties when consummating a trade with the second party. 
One would have been motivated to allow the user to exclude others in order to prevent 
a barrage of conflicting bids/offers from arriving while the user is attempting to complete 
the transaction with the second party. 

Claim 37: Kramer and McCausland each disclose a computer trading system 
with a custom designed keyboard as in Claim 16 above, but neither explicitly disclose 
that the keyboard would contain a plurality of buy and sell keys with one buy key and 
one sell key assigned to each of a plurality of specific securities. However, Kramer 
discloses using special function keys on the keyboard to provide simplified data entry 
and further discloses altering these function keys to provide the desired functionality (col 
3, line 63 - col 4, line 4). McCausland also discloses a special purpose keypad with a 
variety of special functions assigned to the function keys. While one exemplary 
mapping is disclosed, it is also disclosed that "other mappings of keypad 200 are 
possible and are contemplated" (col 6, line 40 - col 8, line 23). Thus, both references 
disclose that the keys on the keyboard/keypad may be altered to provide the desired 
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functionality. The Examiner also notes that it is common for data processing keyboards 
to have 10-12 programmable function keys. Therefore, it would have been obvious to 
one having ordinary skill in the art at the time the invention was made that a plurality of 
buy and sell keys could be set up, one pair for each desired security. One would have 
been motivated to set up special buy and sell keys for specific securities in order to 
increase the speed in which the operator could enter selections as discussed as being 
desirous by both references. 

(f) Claim 19 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
Kramer (5,038,284) in view of McCausland et al (5,243,331 ). 

Claim 19: Kramer discloses a computer trading system as in Claim 16 above, 
but does not explicitly disclose terminating the bid/offer state upon entry of a hit or lift. 
However, McCausland discloses a similar computer trading system in which the 
bid/offer state is terminated upon entry of a hit or a lift (col 24, lines 64-67). Therefore, it 
would have been obvious to terminate the bid/offer state in Kramer when a hit or lift was 
entered. One would have been motivated to terminate the bid/offer state in order to 
allow the trader to process other actions after the pending bid/offer had been fulfilled by 
the hit or lift. 

(11) Response to Argument 

(a) The Appellant argues against the rejection of Claims 1-5, 7-15, and 34-36 
under 35 U.S.C. 1 12 for failure to describe subject matter in the specification in such a 
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way to enable one skilled in the art to make and/or use the invention, which was 
directed to the phrase "in excess of what the aggressor participant may have intended". 
The Appellant has cited several passages from the specification as enabling the system 
to determine if the hit or lift trade command was in excess of what the aggressor 
participant may have intended (pages 26-. However, these passages merely define a 
situation in which the aggressor participant "has now taken more than he planned" and 
the system will create "a Second Look State whenever a hit/lift ... occurs while a 
Bid/Offer is under, e.g., two seconds old." Creating a Second Look State based on the 
time between the bids/offers is not determining that the aggressor participant's bid/offer 
is in excess of what the participant may have intended. The present system will create 
this Second Look State for any bid/offer received within 2 seconds, whether or not the 
particulars of the bid/offer (e.g. price, quantity, etc.) have been determined to be outside 
of what "the aggressor participant may have intended". Therefore, the Examiner stiii 
asserts that the specification does not support nor disclose any steps that could be used 
to determine what the participant may have intended when he entered a bid/offer, such 
as using artificial intelligence or "fuzzy logic" to compare the bid/offer parameters to a 
predefined set of parameters to determine if the bid/offer falls within acceptable 
tolerances. 

(b) The Appellant argues against the rejection of Claims 1-5, 7-18, 20-23, and 
34 under 35 U.S.C. 102(b) as being separately anticipated by McCausland and Kramer . 
The main thrust of the Appellant's arguments are that the two references do not 
disclose their systems entering various "trade states" during a trade (pages 30-35). 
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Initially, the Examiner notes that while the two references use different terminology that 
the Appellant, they disclose the functionality of the claims (Claim 1 : presenting 
information about pending market conditions, execute trade commands (hit or lift) 
entered by the traders, and enabling the traders to decline (delete) a previously entered 
trade). The Appellant is using computer programming "buzzwords" terminology of the 
late 1980's when the computer programming practitioners were changing from the 
standard flow-chart method of diagramming computer programs to the "state diagram" 
method whose notation was developed by David Harel in 1987. Essential to the 
understanding of the Appellant's argument is a discussion of how "state diagrams" are 
used and what they contain. While State Diagrams had been used to diagram electronic 
systems for many years, this was a new method for diagramming computer programs 
and used "events" and "states" to describe what is happening in the computer. An 
Event is something that happens at a poini in time, such as useriifts ihe telephone 
receiver. A State corresponds to the interval between two Events, for example, when a 
telephone receiver is lifted (Event) and before the first digit is dialed, the telephone is in 
the State of Dial Tone. A state diagram relates Events and States. The next State 
depends on both the previous State and the received Event. The Examiner is including 
an example of a state diagram of a telephone system to help clarify the issue 
(Raumbauqh et al , "Object-Oriented Modeling and Design", pages 84-91). In the 
diagram, the rounded boxes are the States, such as "Dialing", "Ringing", "Busy Tone", 
etc. The lines connecting the rounded boxes are Transitions, each of which correspond 
to a different Event, such as "called phone answers", "called phone hangs up", etc. This 
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type of notation can be used to describe other types of systems to include the trading 
systems disclosed by the Appellant's, McCausland 's, or Kramer 's. For example, 
Kramer discloses the steps performed to execute a transaction in column 12, lines 3-61 
consisting, in part, of (a) "each trader presses his ENTER key"; (b) "the message is sent 
to the host and processed"; (c) "the host notifies each PTS that messages are being 
corrected received"; ... (d) the trader depresses the RCN "to display all the data for the 
transaction" when a mismatch occurs; etc. In a normal flow chart displaying this 
system, each of the above steps would appear in one of the boxes of the flow chart. If 
the same system was diagrammed using a State Diagram, the above steps would be 
described as (a) State: Data Entry; (b) Event: ENTER key depressed; (c) State: PTS 
Outgoing Transmission; (d) Event: Message is transmitted to host; (e) State: Host 
Incoming Transmission; (f) Event: Message is received and processed; (g) State: Host 
Outgoing Transmission; (h) Event: Message is transmitted to PTS; ... (i) State: 
Mismatch; G) Event: RCN button depressed; (k) State: Display; (I) Event: data retrieved 
and displayed; etc. Each of the States would be displayed in the rounded boxes of the 
State Diagram and each of the events would be associated with the appropriate lines 
connecting the State boxes. 

As shown, the use of "State" terminology in the claims is merely an alternative 
way of addressing the functionality of the computer programmed to perform the 
invention. Therefore, the Appellant's argument that the two references cannot disclose 
the claimed invention because they do not refer to their systems transitioning from one 
state to another as claimed is, in the Examiner's eyes, non-persuasive. 
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As per the Appellant's argument that neither reference discloses that "in 
response to detecting that an aggressor participant's hit or lift trade command would 
execute a trade in excess of what the aggressor participant may have intended, 
automatically enables the aggressor participant to decline, prior to execution, at least a 
portion of only the excess part of the trade" (page 34), the Examiner notes that Kramer 
discloses the system tracks the time between the receipt of the trades (from the buyer 
and seller) and automatically identifies trades with "time marking differentials exceeding 
an acceptable level" (col 6, lines 48-52) and further discloses that the trader may use 
the keys on the portable device (PTS) "for automatically negating a transaction and for 
automatically voiding a transaction" (col 5, lines 57-59). Thus, it is disclosed that the 
system will verify that the time does not exceed a designed limit (such as the argued 2 
seconds) and will allow the trade to decline (negate or void) the transaction prior to 
execution. 

(c) The Appellant argues in reference to the rejection of Claims 16-18 and 20-23 
that neither reference discloses a custom keypad with a "plurality of trade execute keys, 
programmed to be individually assigned to a particular security available for trading" 
(pages 35-36). Initially, the Examiner notes that in response to the arguments 
presented herein by the Appellant, the rejection above has been changed to incorporate 
the language of a 102/103 alternative rejection. Thus, the 102 rejection of these claims 
has been maintained, but an alternative 103 rejection has been added. In addition to 
this, the following response to the argument is given. As presented in response to this 
argument in the Final Rejection, the Examiner noted that McCausland 's disclosure that 
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many different mapping of keys to function can be made renders it a design decision by 
the user on how to program (map) each key. Likewise, Kramer explicitly discloses that 
the user can program the function keys to perform specific functions. Programming 
such special function keys to allow a one button purchase or selection is rampant 
throughout our society. For example, most fast food restaurant cash registers have 
large keypads with separate buttons for each of the products. The salesperson only 
has to press a single button in order to indicate a purchase of that product. In each 
case, the manager has the option to (re)program the buttons to the desired function. 
Both references disclose similar reprogrammable keys on their keyboards. As noted 
above, it would be a design decision of the user on how the various keys would be 
programmed. If the user consistently needs to access a few specific commodities, it is 
obvious that the user would program keys for these commodities. If, on the other hand, 
the user was a "generalise and covered dozens or hundreds of commodities with similar 
frequency, then the user may want to program the keys to perform other frequently used 
function instead. Again, this is a design decision that does not affect the steps of the 
claimed method of trading. Furthermore, the Examiner notes that if the trader of the 
Appellant's invention actively traded 10 or 20 such securities, the claimed keyboard, 
with separate buy and lift keys for each security, would quickly become too 
cumbersome to operate with any kind of efficiency. On such a system it would be much 
more efficient to have only one hit key and one lift key and to program the other 
functions keys for each desired security. The trader then would only need to press two 
keys - the desired security key and the buy or lift key. The Appellant's argues against 
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the "fast food cash register" example cited by the Examiner in the final response by 
classifying the keys on the cash register as "not trade execute keys because they are 
not used to execute trades. Instead, they merely record an intended trade. If the keys 
used in the restaurant were trade execute keys (which they are not), depressing a key 
would effect the physical transfer of a hamburger from the restaurant's inventory into a 
buyer's possession and the transfer of funds from the buyer to the restaurant." (page 
38). The Examiner notes that the depressing of the "trade execute" key in the 
Applicant's invention, likewise, does not effect a physical transfer of the security to the 
possession of the buyer, but merely initiates the purchase (or sale) of the security. The 
actual security is delivered to the buyer at some later time. In any case, the fast food 
restaurant example was not used to show that restaurants initiate security trades, it was 
used to show the widespread use of keyboards with programmable keys which can be 
programmed to identify individual products (e.g. securities). Even the standard 
keyboard used in the general purpose personal computers throughout the world have 
several programmable "Function Keys", which the user may program to perform a 
specific function. Since both of the references also disclose such programmable 
function keys on their keyboards along with other keys which are used to execute trades 
(e.g. hit, lift, quantity, reconsider (RCN), etc.), it would have been inherent, or at least 
obvious, to program the function keys for specific, heavily-used securities. 

(d) The Appellant argues in reference to the rejection of Claim 4 that neither 
reference discloses "that an aggressor participant and a first-in-time pf the passive 
participants may trade additional volume of an item with each other to the exclusion of 



Application/Control Number: 09/859,661 Page 20 

Art Unit: 3622 

other participants desiring to trade" (pages 39-40). The Examiner notes that 
McCausland asks the user to Confirm or Reject the second party's bid/offer (col 20, 
lines 58-61) and discusses the differences between a "single-order" (i.e. exclusive) 
trades and a "multi-order" (i.e. non-exclusive) trader (col 22, lines 41-63) and how partial 
hits or offers are handled (Col 24, line 64 - col 25, line 3). Kramer discusses at length 
how two traders resolve conflicts with unreconciled trades through one-on-one 
negotiations (i.e. exclusive)(col 12, lines 38-61). Therefore, both references disclose 
allowing the first party (aggressor participant) to include or exclude other traders when 
consummating a trade with the second party (passive participant). The Examiner notes 
that Official Notice was also taken on this feature in the rejection of Claims 31-33, 35, 
and 36 above. This will be further discussed in response to the Appellant's arguments 
to the Official Notice statement below. 

(e) The Appellant argues in reference to Claim 19 that McCausland does not 
disclose "terminating a Bid/Offer state upon entry of a hit or lift", but "merely shows 
canceling a previously existing bid or offer made by the same trader who enters a hit or 
lift command" (pages 40-41). The Examiner notes that as discussed above in reference 
to "trading states", it is inherent that upon entry of an Event, the current State is 
transitioned to a new State based on the Event. Therefore, even notwithstanding the 
cited passage from McCausland , upon entry of a hit or lift command by a trader in 
McCausland the State of the system would change from Bid/Offer to "Consummate 
trade" or whatever name the designer has given the next State. However, in all 
circumstances, the previous State (Bid/Offer) would be terminated and the next State 
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would be entered. McCausland 's disclosure of canceling a previous bid or offer when 
the trader enters a hit or lift command also terminates the previous State and enters the 
new State based on the hit or offer entry Event. 

(f) The Appellant argues in reference to the rejection of Claims 31-33 and 35-37 
that the two references and the Dutch Auction are not combinable (pages 41-49). The 
initial arguments of these claims repeat the "trade commands" and "chance to amend or 
cancel the trade" arguments in reference to Claim 1 above. The Examiner refers the 
Board to the response to those arguments above. As per the Dutch Auction argument, 
the Examiner notes that Official Notice was taken in both previous rejections "that it is 
old and well known in the negotiation and auction arts that third party participants can 
be allowed to participate (included) or prevented from participating (excluded) during the 
negotiation and consummation of a transaction between the first and second parties", 
and cited a Dutch auction as exemplary of such inclusion or exclusion. In response to 
the Appellant's attempt to traverse this Notice, the Examiner provided the Dutch Auction 
reference as the Appellant requested. Thus, the Examiner has not attempted to 
incorporate the Dutch Auction reference into the other two references, but merely used 
it to provide support for the Officially Noted fact. The Appellant's argument against the 
combination of the other two references in the rejection of these claims is mute in that 
the two references were not combined in the rejection, but rather were each separately 
combined with the Official Notice. The Appellant's argument in reference to Claim 37 
(Pages 48-49) repeats the argument pertaining to the plurality of trade keys in reference 
to the rejection of Claims 16-18 and 20-23. The Examiner refers the Board to the 
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detailed discussion of this argument above. As to the Appellant's argument in reference 
to Claim 36 (page 49) that the Examiner has not addressed the feature of automatically 
executing the trade upon expiration of a time period, the Examiner notes that in the 
rejection of this claim above, this feature fell under the Official Notice and was shown in 
the Dutch Auction example that it was well known to give the second party "a specified 
amount of time, such as two minutes, in which to consummate the trade". Upon 
expiration of the time period two possible actions could be taken by the system - either 
automatically consummate the trade or automatically cancel the trade. The selection of 
which of these actions to perform would depend on the rules and regulations installed 
into the system during its set-up (and possibly current legal standards). 

(g) The Appellant argues against the 35 U.S.C. 103 rejection of Claim 19 over 
Kramer in view of McCausland by repeating the argument previously presented in 
reference to Claim 19 above that McCausland does not disclose "said Bid/Offer State is 
terminated by a participant entry of a hit or lift command" (page 49). The Examiner 
refers the Board to the detailed discussion of this argument above. 



For the above reasons, it is believed that the rejections should be sustained. 
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